In wireless telecommunication systems information is transferred in an encoded form between a transmitting communication device and a receiving communication device. The transmitting communication device encodes original information into encoded information and sends it to the receiving communication device. The receiving communication device decodes the received encoded information in order to recreate the original information. The encoding and decoding is performed in codecs. Thus, the encoding is performed in a codec located in the transmitting communication device, and the decoding is performed in a codec located in the receiving communication device. However, since there are many different codecs available, the transmitting terminal and the receiving terminal have to agree upon the codec(s) to be used in a session. This agreeing procedure occurs during the initial session establishment and is called a codec negotiation procedure.
The codec negotiation procedure for third generation (3G) telecommunication systems is currently being standardised. One of the standard proposals for a codec negotiation procedure for third generation telecommunication systems is discussed in the following with the aid of FIGS. 1 and 2.
FIG. 1 shows a third generation telecommunication system for providing codec negotiation. In the system there is formed a signalling chain between a first communication device (hereinafter referred as UE1, UE standing for User Equipment) and a second communication device (hereinafter referred as UE2). The signalling chain goes through a first Proxy Call State Control Function (hereinafter referred as P-CSCF1), a first Serving Call State Control Function (hereinafter referred as S-CSCF1), a second Serving Call State Control Function (hereinafter referred as P-CSCF2), a second Proxy Call State Control Function (hereinafter referred as S-CSCF2). P-CSCF1, S-CSCF1, P-CSCF2 and S-CSCF2 are logical network entities that may be implemented so as to form separate physical network elements, or they may be incorporated in some of the already existing physical network elements. P-CSCF1 and S-CSCF1, for example, may be incorporated in a first GGSN (Gateway General Packet Radio Service (GPRS) Support Node), and they may be controlled by a first network operator. P-CSCF2 and S-CSCF2 may be incorporated in a second GGSN, and they may be controlled by a second network operator. Interfaces between the different devices and functions mentioned above are defined in 3GPP (3rd Generation Partnership Project) specifications. It is known to a person skilled in the art that network elements and/or control functions other than the ones shown in FIG. 1 may reside in the system.
The P-CSCF1 and S-CSCF1 are, among other things, responsible for providing services and reserving resources (for example radio resources) for the UE1. The P-CSCF1 controls the UE1 so that it does not exceed the resources that the network is able to provide for it. The S-CSCF1 controls the UE1 so that it does not exceed the resources to which its user has subscribed.
The P-CSCF2 and S-CSCF2 are, among other things, responsible for providing services and reserving resources for the UE2. The P-CSCF2 controls the UE2 so that it does not exceed the resources that the network is able to provide for it. The S-CSCF2 controls the UE2 so that it does not exceed the resources to which its user has subscribed.
When the UE1 initiates a session with the UE2, the codec to be used for the session is to be determined (negotiated). If the session is going to be a multimedia session that is the session is going to be established with more than one media stream (for example an audio stream and a video stream) codecs to be used with each of the streams are to be negotiated.
According to the standard proposal (3G TS 23.228 version 1.7.0) the negotiation is performed in such a way that the UE1 (also referred to as the session originator) first generates, according to the SIP (Session Initiation Protocol) protocol, a SIP INVITE message comprising particular SIP header fields and a message body. According to the proposal, the message body is generated according to the SDP (Session Description Protocol) protocol and it is called an SDP body.
The UE1 generates the SDP body in such a way that it contains a list (set) of codecs that the UE1 is able and willing to support for the session. The UE1 sends the SIP INVITE message to the UE2. When the SIP INVITE message arrives at the UE2, the UE2 responds to the UE1 by generating and sending a reply message, also containing an SDP body, to the UE1. The reply message is referred to in the SIP protocol as the “183 message”. The SDP body of the reply message contains a second list of codecs indicating the codecs that the UE2 is able and willing to support for the session. The second list is generated based on the content of the list of codecs in the SDP body of the SIP INVITE message and based on the UE2's ability and willingness to support these codecs. If the UE2 is able and willing to support all the same codecs as the UE1 this results in the second list of codecs being the same as the (original) list of codecs that the UE1 generated in the first place. However, if the UE2 is not able or willing to support, for the session, one or more of the codecs contained in the original list, the UE2 leaves such a codec or such codecs out from the second list. This being the case the second list is a sub-list of the original list. In either case, the second list contains the codecs that both the UE1 and the UE2 are able and willing to support for the session.
When the 183 message, sent by the UE2, arrives at the UE1, the UE1 decides which codec (or codecs if it is a multimedia session) of all of the supported codecs contained in the second list is (or are) to be used in the session. After it has decided this it sends to the UE2 a third message (referred to as the Final SDP) which tells to the UE2 the codec(s) that is (or are) to be used in the session to be established.
However, if the messages are sent in an end-to-end manner as described above a problem arises, because the decision of the codec(s) to be used is made without determining from the network the capacity that it is able to provide. For example, the chosen codec might be such a codec that requires a larger bandwidth than the network is able to provide at the time in question.
One standard proposal tries to solve this problem by allowing the network entities P-CSCF1, S-CSCF1, S-CSCF2 and P-CSCF2 to remove non-suitable codecs from the codec list in the SDP of the SIP INVITE message. In the following the matter is described in more detail referring now to FIG. 2.
After the UE1 has determined the codecs that it supports for the session it sends the SIP INVITE message to the UE2. When the SIP INVITE arrives at the P-CSCF1, on its way to the UE2, the P-CSCF1 removes all non-suitable codec choices from the codec list in the SDP body. By a non-suitable codec choice is meant such a codec in the codec list that is, at the moment (or in general based on a network operator policy), not possible for the session from the network's point of view, the network being the one serving the UE1. One example of a non-suitable codec choice would be a codec that uses too large a bandwidth compared to the bandwidth available in the network.
The P-CSCF1 forwards the message to the S-CSCF1 which removes from the codec list all codecs that the UE1 is not authorised to request (based on user subscription information relating to the user of the UE1).
The S-CSCF1 forwards the message to the S-CSCF2 which removes from the codec list all codecs that the UE2 is not authorised to use (based on user subscription information relating to the user of the UE2).
Also, the S-CSCF1 and S-CSCF2 remove from the codec list all codecs that are not supported based on a network operator policy.
The S-CSCF2 forwards the message to the P-CSCF2 which removes all non-suitable codec choices from the codec list in the SDP body. Again, by a non-suitable codec choice is meant such a codec in the codec list that is, at the moment (or in general based on a network operator policy), not possible for the session from the network's point of view, the network now being the one serving the UE2.
Finally, the P-CSCF2 forwards the SIP INVITE message to the UE2. The UE2 receives the SIP INVITE message containing the SDP body which now comprises a list of codecs which both the UE1 and all the logical network entities P-CSCF1, S-CSCF1, S-CSCF2 and P-CSCF2 are willing to support for the session.
The UE2 now responds with a reply message (that is the 183 message) containing a second list of codecs. The second list is generated based on the content of the list of codecs in the SDP body received in the SIP INVITE message and based on the UE2's ability and willingness to support these codecs. If the UE2 is able and willing to support all the codecs contained in the list of codecs, received in the SIP INVITE message, the second list is the same as the list of codecs, received in the SIP INVITE message. If the UE2 is not able or willing to support, for the session, all the codecs contained in the list of codecs, received in the SIP INVITE message, the UE2 leaves such a codec or such codecs out from the second list. In either cases, the second list is a list of codecs that both the UE1 and the UE2 and all the network entities P-CSCF1, S-CSCF1, S-CSCF2 and P-CSCF2 are willing to support for the session.
When the 183 message arrives at the UE1 it can make a choice which automatically takes into account the network capabilities, when deciding the codec(s) to be used initially in the session. Information on the chosen codec is sent to the UE2 in a Final SDP message, in a manner similar to that previously described.
The method described above only indicates whether a particular codec is supported or not. However, there exist codecs which have multiple options. An AMR (Adaptive Multi Rate) codec, for example, is a codec which supports a plurality of different bit rates. In this case it is not enough in the codec negotiation procedure just to indicate whether the AMR codec is supported, but there is a need to indicate the bit rates of the AMR codec that are supported.